This document was downloaded and archived from http://itrb.gov/itrbpmp.htm on May 30, 2001.

Table of Contents

Beginning of Document

What is your agency’s mission? What is the relationship of your project to your agency’s mission? Project activities need to support this mission.

Know the Project Stakeholders

A strong project mission can not be created in a vacuum. Who are the people with an interest in the outcome of the project? What are their common expectations? Stakeholders’ expectations are rarely spelled out in legislation, executive orders, or formal memoranda.

Amplify the Voices of Your Customers

Who will be paying for this project? Who will actually be using the systems and processes being designed? Clarify the business priorities of these customers and their criteria for success. Actively and emphatically communicate this information. Do this for customers inside the organization as well as those outside the organization.

Maintain High-Level Communication About the Project Mission

Communicate steadily with stakeholders and customers throughout the project. This will help to manage their expectations and requirements over time. Design project development so that requirements and expectations can be reconfirmed at regular junctures. Periodically check to see that stakeholders and customers understand and support changes, delays, and new developments.

Strategies
What do you want to accomplish?

Set Realistic Business Objectives

What are the common business needs of the organizations that will depend on the system? What accomplishments will be critical for the project to be considered successful? Define project boundaries at the outset, and use this definition to manage requirements throughout the project. A clear definition of business success will also help ensure that project efforts support the agency’s strategic plan.

Define a Sound Architecture

Drive Toward an Enterprise-Wide Business Model

Ensure that the business model meets business objectives while remaining within the project’s scope. Publish a detailed concept of operations which distinguishes clearly among the business model, the layout and relationship of systems and communications, and the technical architecture. These should be anchored in an enterprise-wide IT strategy.

Implement Systems Incrementally

Work toward a systems implementation that will deliver, in twelve months or less, incremental, useable levels of functionality which support specific business objectives. The detailed concept of operations should explain how the architecture will satisfy these objectives and how it will prioritize them. It should also communicate responsibilities for implementing and managing the architecture.

Coordinate Technical Standards

Which standards are essential to ensure that the technical architecture ultimately supports business objectives? Define these, paying particularly close attention to technical interfaces. Develop a plan to ensure compliance with architecture standards. The technical architecture must be documented to ensure its consistency with the overall agency-level design.

Gain Agreement on the Project Plan

The project plan formally captures and documents agreements among customers, stakeholders and project participants. Secure an informed agreement up front, and maintain this agreement throughout the project life. This will ensure that the project meets expected results. This will also help align the project with the organization’s business plans and supporting IT plans. Over time, manage the project scope carefully, since there will be a tendency for different areas of the project to acquire their own divergent momentum.

People
Understand the project participants

Organizational Leadership

Listen to the Customer and Create a Vision

The project sponsor manages high-level customer relationships, translating key customer expectations into a practical vision for the project. To be effective, this vision must be broadly communicated.

Commit to the Project

The most frequent cause of project failure is the lack of involvement of the organizational leaders. Ongoing involvement is crucial. It is critical to structure the project in such a way that go/no-go decisions may be made at highly visible milestones. Leadership commitment stabilizes the project so that it can accommodate changes over time.

Leverage the Existing Organizational Structure

The roles and responsibilities of the project and its partners are most effective when they correspond with the way in which the overall agency is managed. For example, in an organization in which field offices have a great deal of autonomy, a centralized approach to IT management could bring about unnecessary conflict.

Empower the CIO

The Chief Information Officer (CIO) position requires extraordinary qualifications in both IT management skills and general management skills. The CIO needs authority and visibility to guide the organization in key decisions. The CIO focuses on three things:

Synergy. Bring realistic synergy to IT strategy by focusing disparate IT activities on their contribution to the organization’s mission. Ensure that business objectives take precedence over technological advances. Direct architectural compliance across the enterprise. Create a formal strategic IT plan that reflects business priorities.

Sharing. Leverage the centralized technical authority to reduce redundancy across different organizational units. Enable them to share systems and data, as well as IT training, approaches, and other commonly needed resources. Coordinate a coherent strategy for commercial off-the-shelf software. Seek to make the enterprise technologically seamless.

Support. Establish complementary managerial and technical structures to provide support for critical enterprise functions. Do this in a way that provides different organizational units with the flexibility they require.

Project Leadership

Select a Strong Project Manager

Empower a central point of responsibility for project decisions, and clearly distinguish this role from functional program management roles. Clarify the risks which the project manager is expected to manage strategically. "Leadership ability" is difficult to articulate, and even more difficult to find. At a minimum, it includes the following characteristics:

Drive. Does the project manager have a strong desire to succeed?

Ability to Build Consensus. Can the project manager get key individuals to work together towards common ends?

Ability to Take Risks. Can the project manager recognize opportunities and find ways to seize them?

Ability to Communicate. Is the project manager able to communicate clearly and convincingly to all parties?

Experience. Does the project manager have a track record of success? Look for characteristics and experiences that relate directly to the project at hand.

Technical Knowledge. Does the project manager possess demonstrated knowledge in the appropriate technical fields?

Sense of the Big Picture. Does the project manager understand the project from a broad business perspective?

Enable a Cooperative Environment

Nurture cooperation among members of the leadership, including the project sponsor, functional program manager, project manager, contracting officer and contractor. Create a learning environment which attracts individual skills to the table. Actively encourage team members to innovate by rewarding judicious risk-taking.

Ensure Accountability

The project manager is responsible for results. Successful project managers actively encourage team members to make minor challenges known before they become major problems. The project needs a "truth culture" – let the messenger live. Stress the importance of accountability by systematically introducing constructive criticism into current practices. One recommended technique is to outsource for independent validation and verification (IV&V) support. It is critical for the executive leadership to listen to IV&V advice. Another technique is to create an anonymous channel for reporting problems.

Project Team Members

Get What’s Needed to Succeed

What are the competencies of the team? How does the staffing plan distribute these competencies against project tasks? Assess the team’s particular strengths, then get the additional expertise needed. There may be a need to outsource for additional skills to round out the team. Balance the mix of management and technical expertise, and the mix of contractor and government personnel. Distinguish between critical strategic activities and tactical activities. Make use of consultants to leverage the team’s capabilities.

Keep the Core Team Together

Maintain a commitment to the integrity of the core team. The project should include the project manager, the functional program manager, the contracting officer and other key players from project conceptualization through implementation. Empower a central point of responsibility for technical decisions, including standards and architecture.

Monitor Team Productivity

How does the level of effort contribute to project deliverables and results? How is the team progressing against the project plan? Perform periodic cost-benefit analyses and life cycle cost estimates. This information will be needed for go/no-go decisions at major project and contract milestones.

Develop Competencies Over Time

Invest in building competencies in key people. Institute and follow a formal plan for skills training and career development. Align the competencies of team members with the long-term needs of the project.

Processes Making it happen

Planning

Define Success Up Front

Define project success in terms of specific business objectives. From the customer’s point of view, how should different business objectives be prioritized?

Use Metrics to Focus On Outcomes

Focus on outcomes rather than outputs. Prioritize the metrics for which project participants will be held responsible. Gain agreement on critical metrics and use them to drive planning and delivery.

Integrate Planning Activities Across the Project

Formalize planning processes. Assign roles and responsibilities specifically for planning-related activities. The CIO can help anchor project plans in the organization’s business and IT plans.

Realign Plans Over Time

How will plans need to be modified along the way? Make sure project plans continue to support intended business priorities. If the project encounters significant changes, then the original plans will have to be realigned to ensure desired results.

Managing Technology

Choose an Appropriate Development Model

Base selection of a development model on careful consideration of four factors:

Costs. Consider various development alternatives and estimate how they might contribute to project costs.

Risks. Consider how much risk the project faces due to:

• High visibility due to public or political attention or requirements
• Highly compressed development time
• High uncertainty associated with the system’s requirements, the technology that the system will employ, or the way that the system will affect business processes

Complexity. Consider the project to be complex if it:

• Affects many organizations or functional areas.
• Results from business process reengineering, dramatically altering the use of information technology.
• Requires new or rapidly advancing technology.
• Requires a long time for development.

Type. Consider the general type of the project:

• A new development
• A modification of an existing system
• A system integration

Select an Appropriate Life Cycle

The life cycle provides an organizing structure with which to align project objectives with appropriate technologies and resources. Different projects require different degrees of rigidity in the sequencing of their phases. Long, complex projects intended to modify familiar systems typically yield to more rigid sequencing. On the other hand, less rigid sequencing may be required to achieve a series of innovations under conditions of high uncertainty.

Deal with Shifting Priorities

Business needs may change. All requirements must be formally managed. Address downstream changes in the life cycle through systematic risk assessment.

Make Progress Visible to All

Project participants need a clear idea of how well the project plan is working. Establish a set of key progress indicators and make them visible to all project participants.

Know The Limits of Automation

Don’t simply automate existing processes. Rethink existing processes instead of simply "paving the cowpaths." If your agency lacks the skills, use consultants to facilitate business process reengineering (BPR) and information modeling prior to defining requirements.

Leverage Expertise in Established Management Areas

Managing Inputs. Encourage project participants to address evolving technical priorities with appropriate resources. For example, employ contract incentives to deliver the desired results in accordance with the projected cost and schedule. Offer high incentives (18 - 20%) to in-house staff.

Managing Activities. Use scope management techniques such as a Work Breakdown Structure (WBS) to organize project activities and tasks. Graphically display the work to be accomplished. Update the display periodically to reflect reality.

Managing Outcomes. Encourage all staff to identify potentially problematic outcomes. Use formal risk management techniques to anticipate and mitigate project risks.

Controlling Tasks

Put Meaning in the Metrics

Define requirements so that they may be thoroughly tested and validated at the unit and systems level of granularity. Identify frequent milestones with a defined set of measurable pass/fail performance criteria. Structure related contracts so that they reflect the same units, granularity, and milestones. This enables you to measure earned value throughout the contract life. These criteria should comply with a pre-established test plan.

Leverage Expertise in Control Areas

Controlling Inputs. Conduct life-cycle cost analysis to evaluate the impact of design implementation alternatives throughout the project. Use agreed upon plans to control the resources applied to the project. For example, periodically review actual project expenditures and compare them to the projected budget.

Controlling Activities. Standardize processes which deal with the most routine activities. For example, routine progress reports can be structured to capture and highlight exceptions from anticipated progress.

Controlling Outcomes. Use configuration management processes to ensure the project is building what the customer wants. The implications of changes along the way can be understood and incorporated while driving toward the desired result.

One ITRB-reviewed project was situated within an agency which had recently undergone major budget reductions and large-scale structural changes. Because senior management was unclear about customer expectations, the agency had been unable to articulate a clear strategic view of the project and its role in the new environment. Customers had insufficient information to guide them in improving work processes. The ITRB recommended that the agency work with customers to accelerate development of a new strategic plan, and that it publish a concept of operations to communicate how the system would operate in future years.

One ITRB-reviewed project reversed its declining fortunes by making substantial revisions to project requirements several years into the project. Project leaders had conducted an evaluation of requirements, leading to large but necessary reductions in both scope and requirements. Though initially disorienting, this reduction did much to stabilize the project, leading to a significantly improved outlook for project success.

The ITRB encountered a project which, after eight years of planning, had yet to define an architecture. The project had come to rely heavily upon the functional program knowledge of the technical contractor, and there were insufficient technical resources involved in crucial technology decision-making. The ITRB recommended that the organization establish technical requirements for deliverables, define modular delivery of specified interim products, monitor product delivery, and generally strengthen the role of contract management.

The architecture should provide a focal point for project definition and clarity. Indeed, ambiguity surrounding this fundamental concept may be a clue that your architecture requires attention. One ITRB-reviewed project exhibited a number of inconsistencies in its use of the term "architecture." This led to conflicting expectations when information about the architecture was disseminated among project participants. Upon closer inspection, the ITRB found that the architecture required broad realignment with the organization’s strategic plan and budget.

One ITRB-reviewed project had negligible high-level involvement on the part of its organizational leadership. It turned out that no single individual was accountable for providing such leadership. Among other things, this explained the absence of a formal planning process and clear business objectives.

The ITRB encountered one project which had clearly identified the information needs of key stakeholders, but was having great difficulty prioritizing these needs. The centralized organization running the project simply did not have the resources or the authority to provide an enterprise-wide solution to all of its widely distributed lines of business. Among other recommendations, the ITRB noted the need to establish an agency-level CIO who could focus the project architecture on the most critical common needs of the different lines of business.

The Clinger-Cohen Act identifies four core competency areas for CIO’s:

1. Federal Information Resources Management
· Policy and Organizational Knowledge
· Information Resources Strategy and Planning
· IT Acquisition
2. Capital Planning
· IT Performance Assessment
· Capital Planning and Investment Assessment
3. Change Management
4. Managerial/Technical
· Professional Development and Training
· IT Topics
· IT Trends

Project leadership does not simply appear; it must be nurtured. Among all of the projects reviewed by the ITRB, those with the greatest chance for success were those which sought to grow and develop leadership competencies over the long run. Though many aspects of project management may be reduced to defined processes, the development of project management leadership competencies remains a difficult but worthwhile challenge.

One ITRB-reviewed project exhibited no partnership among functional program leaders, IT managers and contract managers. Significant confusion resulted among both contractor and agency employees as to who made key decisions. In the absence of cooperative leadership, critical analysis of functional requirements was seriously lacking. The ITRB recommended that the project not only clarify the respective roles of project team members, but that it reorganize its executive steering committee to make it truly accountable for all final project decisions.

In the majority of reviews it has conducted, the ITRB has recommended that organizations immediately establish a process for independent validation and verification and that executives explicitly consider IV&V recommendations when making decisions.

One ITRB-reviewed project found a significant shortage of staff on the agency management team. The ITRB recommended that the management team take all possible actions to expand its staff, concentrating on the addition of technical expertise in computer software and systems. The ITRB also recommended that contract personnel be more effectively used to provide project management support

One ITRB-reviewed project revealed a clear need to integrate IT planning across various organizational units involved in the project. A new business concept of operations required that IT processes be realigned to meet evolving demands. The ITRB recommended that the organization use experts in BPR and information modeling to facilitate the necessary process analysis and redesign

One agency requested the ITRB review its enterprise-wide architecture. The agency appeared to lack a structured process for testing products within the architecture before placing them into use. The ITRB recommended a centralized test bed which would enable the agency to simulate new functionalities and assess them before placing them into service.

One ITRB-reviewed project faced serious risk of failure due to recent major shifts in the agency’s mission. If carried out according to the original plan, the project would simply have automated certain processes which no longer made sense in the new environment. The ITRB recommended that the organization cease development of certain sub-systems, and retain consultants to facilitate high-level process redesign.

The ITRB reviewed one project which had recently negotiated movement from a cost reimbursement contract to a fixed price contract. While the ITRB concluded that this was an appropriate step, it noted that the agency would need to consider more thoroughly the different risks entailed by the new contract incentives, and that it would need to balance the risk between the agency and the contractor. For example, the ITRB recommended that the agency tie progress payments to accomplishment of specific milestones.

One recently redesigned project lacked test and acceptance procedures for a large set of new technical requirements. The ITRB recommended that the agency establish test and acceptance procedures at frequent milestones consistent with the project’s work breakdown structure. It further recommended that the requirements be re-baselined, and frozen, in order to ensure an acceptable level of functionality.

The ITRB reviewed a project whose software development process was in a perpetual state of change. The ITRB recommended the establishment of configuration management baselines as well as cost and schedule baselines.